The use of cryptographic keys involves trust. When A encrypts data with B's key, A expects that only B will be able to decrypt the data. And when A verifies a signature that was created with B's key, A expects the existence of a valid signature to mean that B actually signed the data over which the signature was calculated. Therefore, when A uses B's key, it is legitimate for A to want to know how A can be sure that B's key really belongs to B, and how can A be sure that B's key has not been compromised.
Trust in keys is generally established through certificates. When an entity creates a key, the entity submits the key to an authority for certification. The authority determines whether the key and its owner meet the authority's standards for certification. If so, the authority issues a certificate for the key, which contains the key signed by the authority. Authorities are entities that are known to the community that they serve, and that the community trusts to certify the keys of other entities. If a recognized authority certifies a key, then the community that trusts the authority will trust the certified key. For example, browsers periodically receive updated lists of authorities, and the browsers will trust certificates issued by authorities on the list. An organization (e.g., a company) may have a certificate authority that is recognized and trusted by machines within that organization.
A trusted platform module (TPM) is a piece of hardware that can be used to provide various forms of security for a machine. One thing that a TPM can do is maintain hardware security around a key, thereby providing a high measure of assurance that the key will not be misused. In some cases, a certificate authority may be willing to certify only a key that is bound to a particular TPM, since this binding ensures that the key will only be used on the machine that contains that particular TPM. Therefore, in order to certify such a key, the certificate authority has to verify that the key is actually bound to the TPM on a particular machine, and cannot be migrated to other machines. Normally, the process of certifying such a key involves several round-trip exchanges between the certificate authority and the client that is requesting to have the key certified. When a client wants to certify a new non-migratable key that is secured by the client's TPM, the client requests that the TPM create a key called an Attestation Identity Key (AIK) for the new key. The client then asks the certificate authority to certify the AIK, which the certificate authority does after verifying that the AIK was actually generated by the TPM on the client's machine. The client then asks the TPM to sign the new key with the AIK, which the TPM will only do if the key is non-migratable. The client then submits the new key and the AIK-generated signature to the certificate authority. The certificate authority trusts the TPM, and has certified the AIK as belonging to the TPM. Therefore, the certificate authority will trust that the new key is non-migratable based on the TPM's having signed it with the AIK, so the certificate authority will issue a certificate for the new key.
A problem with this process, however, is that it involved multiple round trips between the client and the certificate authority: one trip to certify AIK, and another to certify the new key that the client is trying to certify.